As Internet technologies advance, e-commerce, multimedia, business-to-business and other applications must reliably support an increasing volume of data. Large amounts of traffic must be routed while maintaining specified Quality of Service (QoS) levels. QoS refers to the capability of a network to provide consistent levels of service to selected network traffic or applications. QoS levels are particularly important in Online Transaction Processing (OLTP) systems designed to immediately respond to user requests. OLTP involves obtaining input data, processing the data, and performing updates in the system to reflect the processed input data. Most applications use a database management system (DBMS) to support OLTP.
One important factor for database I/O performance is latency. Latency refers to the amount of time it takes to store or retrieve data. Latency is an issue even if the amount of data involved is small. For example, latency is affected as a request travels across switches, within a server's operating system I/O stack, and other hardware in a database system.
Different types of database input and output (I/O) have different sensitivities to latency. For example, in the Oracle™ Relational Database Management System (RDBMS) environment, redo logs are latency sensitive. Redo logs include redo records that provide a history of all changes made to the corresponding database. Redo log I/O is latency sensitive because transactions typically wait for return confirmation that the redo records have been persisted. Therefore, redo log I/O has a large impact on the performance of OLTP systems. Other types of database I/O, such as batch, reporting, and backup-related I/O, are less latency sensitive. Nevertheless, some types of database I/O that are not latency sensitive are significant consumers of network bandwidth. When non-latency sensitive I/O requires high network bandwidth, latency may increase. Database systems must handle both latency sensitive and non-latency sensitive transactions while taking latency sensitivity into consideration. Typical solutions for minimizing latency range from simply rescheduling bandwidth-intensive jobs (e.g. to off hours) to maintaining dedicated OLTP systems.
Thus, there is a need for a solution that effectively utilizes storage network bandwidth while at the same time, meeting the latency requirements for latency-sensitive Database I/O.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.